The Interview Engine provides the core functionality required to conduct an interactive investigation. It is responsible for providing the ability for you to:
To find out how to work with the Interview Engine to create a custom interview client, go to the topic: Create a custom interview user experience.
The Interview Engine is responsible for creating Interview Sessions and managing the list of rulebases available to create interviews for. It provides the following services:
The Interview Engine engine itself is created by passing an engine configuration object to the Interview Engine Factory. These configuration properties control things such as providing information on how and where rulebases should be loaded from and other parameters controlling how Interview Sessions are created and managed. All interview sessions created through a given instance of the engine will inherit the behavior specified by the engine configuration.
The Interview rulebase provides access the abstract definition of screens and flows. It encapsulates a Determinations Engine rulebase, through which the rulebase data model can be accessed. Interview rulebases are required in order to create an Interview Session.
The Interview Session is the core component of the Interview Engine that provides the ability to conduct an interview, get interview screens, add data to a session, retrieve data from a session, generate documents and get commentary. It provides the following services:
A key feature of the Interview Engine is its transaction support.
In Web Determinations, screen and data submissions are considered a single, atomic transaction. Therefore either all the data on that screen will be submitted or none of it will. This transactional support is provided by the Rule Session Manager which acts as a gateway between the Determinations Engine Session encapsulated in the Interview Session. All access to the Determinations Engine Session, both internally and externally is mediated through this layer.
Although the Rule Session Manager is transparent to clients of the Interview Engine API, it does however, have some impacts that users of the API should be aware of. Firstly, while Interview Session provides the ability to get access to the underlying Determinations Engine Session, clients must not modify the data held in the Determinations Engine Session directly but rather use the methods provided by the interview session itself. Secondly, the Web Determinations Session itself is transient and may be destroyed and re-constructed at any point during the life of the Interview Session. This means that references to objects contained in the Determinations Engine Session cannot be cached.
An Interview Screen is the in memory, object representation of a rulebase screen. Unlike the Determinations Engine Screen, an Interview Screen is not an abstract template but rather a specific representation, containing the values, text substitutions etc based on the state of the session. The interview screen is static in sense that it will reflect the data held in the session at the time it was created. This means that if the session data is changed the screen must be reconstituted in order for it to reflect those changes.
The Interview Goal is the object upon which an investigation is preformed during an interview. Unlike previous versions, there is no distinction between an attribute goal and a flow goal. There are two ways of accessing goals; either though the goal service or via a goal control on a summary screen.
For information about retrieving a decision report from an interview goal, refer to the topic Retrieve a Decision Report in an interview.
